With increasing popularity of content streaming services such as YouTube© and Spotify©, the number of users in the mobile space is increasing, and the average traffic load with them. The innovators and early adopters of yesterday are now expecting their mobile devices to handle download faster than before with maintained quality and security. In the wake comes the early-majority comprising experienced desktop users projecting desktop user experience expectations onto the mobile device.
Mobile networks typically feature a wide traffic dispersion range. The load during a few solitary peak hours per day may be 20 times as high as the average traffic load, whereas the load during, say eight, minimum-traffic hours is virtually zero. The traffic load also varies on a weekly and seasonal basis. An un-balanced network must in effect be designed to handle peak level traffic 24-7, all year round, in order to avoid disgruntled customers during the relatively few peak hours. During the off-peak hours, that un-balanced network is consequently an under-deployed liability, rendering lower Return On Assets, to stakeholders' dismay.
Various load-balancing methods have been presented to address the above problems, but in doing so, they cause new ones. According to one method, the delivery of non-critical traffic, e.g. file downloads, is reduced or delayed during peak hours. This is a very crude way of load-balancing, which certainly enables increased system deployment, but at the expense of service quality.
Other methods attempt to cache content locally so that the network does not need to be invoked when the user requests the content. The most common ones are client “agents”, e.g. Google Web Accelerator©, that silently download files a user is likely to access and store it locally until the user requests it. The method reduces peak load at the expense of an acceptable increase in average load. However, the network operator cannot distinguish pre-downloading traffic from other traffic and will therefore bill the end-user for downloading of content that was neither requested nor consumed. This is a major disincentive to employing pre-downloading software.
Yet other methods send encrypted data to the client proactively, storing it as an encrypted file on the system, and then either sending a “decrypt” signal from the network or allowing the user to request or purchase the key to decrypt the data with. The sent data is considered property of the network operator until decrypted. The transfer is not billed, but the act of unlocking the data is. However, these method are non-transparent, as the end result is encrypted data, which may perhaps even require user interaction to purchase an unlock key. They are also susceptible to software tampering.